The invention relates generally to a method for providing software-as-a-service to a plurality of clients. The invention relates further to a portal scoring unit for providing software-as-a-service to a plurality of clients, a related portal server, a computing system, a data processing program, and a computer program product.
User interfaces of modern software applications often involve the use of a portal. Portals provide end-users with a unified access to content, applications, and collaboration services in a highly personalized manner. Portals typically provide a middleware framework and tools for building and managing portals using component applications like, e.g., portlets (self-contained applications or content) or other content resources. A portal receives requests issued by clients, e.g., via a browser, and returns responses comprising markup information and/or data, e.g., in XML format, to the client. Portals may also support multiple pages with menu-based or custom navigation for accessing individualized content and portlets for each page.
Typically, a portal employs an architecture, wherein the portal itself may only implement standard functionality like authentication, state handling, aggregation, access control, and so on, and may provide the infrastructure for application components. This architecture includes APIs (application programming interface) for the integration of applications, so that applications from different sources may be used as long as they match the portal product's API. In the portal environment, these applications are typically called portlets.
Normally in prior art, both, the portal and the portlets are implemented as web applications and are deployed to an application server with the functionality to execute web applications. For example, a conventional portal may be implemented as a web application that contains a servlet that constitutes the main Portal entry point. This servlet accepts the client requests and dispatches to further resources like, e.g., other servlets, portlets or JSPs (Java Server Pages) while processing the request. Typically, a portal resource is created and updated or deleted by one or multiple portal administrators.
Today's implementations of portals often involve also virtual portals, which represent virtual entities, each representing the logic of behavior of the distinct portal but implemented by one single portal server.
A conventional virtual portal has its own unique set of resources such as pages, users, themes, skins, and/or portlet instances. Virtual portals may also have their own directory and thus, may have their own set of authorized users and administrators. Typically, virtual portal administrators manage each virtual portal individually.
Conventional portals provide a strict separation between a virtual portal and a resource such as portal pages and portlet instances. In this context, the term “scoping” denotes making portal resources and portal availability uniquely, and separately, to individual virtual portals and their users.
To realize scoping, a conventional portal maintains an association between a virtual portal and a resource. Each scoped resource may be associated with exactly one virtual portal while a virtual portal may be associated with multiple scoped resources. The association may be represented in the form of a relation, a data structure, or by assigning each resource a unique identifier and including a designation of the associated virtual portal in this identifier. Conventionally, there is no available functionality to share resources between multiple virtual portals.
Each portal request may be targeted at one specific virtual portal. While processing the request, a conventional portal may retrieve and use those scoped resources that are associated with the virtual portal targeted by the current request. The conventional portal components provide only a view on scoped resources filtered for the current virtual portal.
If a portal administrator wants to make resources available for use in multiple different virtual portals, copies of the resources need to be created and deployed, one copy for each of the virtual portals. This not only creates significant data redundancy and increases the memory consumption of the portals, worsening performance, but it also complicates the administration of the portal.
Basically, to create a resource in a virtual portal, a portal administrator may perform the following steps: (i) select the virtual portal, for example, the administrator may implicitly select the virtual portal by using a portal URL (universal resource locator) that designates the virtual portal; and (ii) create the resource by using the conventional portal administration functionality. A portal creates the resource in the currently selected virtual portal, i.e., it creates the resource identifier to contain the identifier of the selected virtual portal. The data that represents the resource is stored in the portal database.
Multi tenancy in a portal-as-a-service infrastructure may be provided for by creating a virtual portal for each tenant. That is, the portal administrator may create one virtual portal specifically for one tenant and may configure the virtual portal according to the tenant's requirements. This may include creating the required portal resources in this virtual portal. The administrator may also define a user directory for the virtual portal, which includes the users that are associated with this specific tenant. Users that are not included or authorized in this user directory are not allowed to use this virtual portal.
Several publications address web applications such as portals in a cloud or multi-tenant environment. Patent document US 2013/0263209 discloses an apparatus and methods for managing applications in multi-cloud environments. “The system comprises a service console configured to store management policies. Each management policy corresponds to a respective application deployment on one or more clouds and indicates one or more potential runtime conditions and one or more corresponding management actions.”
Patent document US 2010/0049637 discloses mapping portal applications in multi-tenant environment. “A method implemented in a computer infrastructure to associate each of a plurality of tenants with a respective virtual portal and individually meter virtual portal usage at each respective virtual portal.”
Using conventional technologies, portal resources, such as pages, portlet instances, themes, and skins, are associated with precisely one virtual portal. In a multi-tenant portal-as-a-service infrastructure, portal resources are often required for all tenants or at least some of the tenants. Because resources cannot be shared between virtual portals, the portal administrator has to create resources separately for each tenant's virtual portal. This may create a significant redundancy in the portal data. Copying resources is a manual process that tends to be error prone and increases administration costs.
Because resources are duplicated, or even multiplied, in the portal model and portal database, the costs of memory consumption and garbage collection increase significantly. As a consequence, portal performance deteriorates and operating expenses (e.g., for additional hardware) for the portal service provider may rise.
Embodiments of the present invention recognize that there is a need to address the above-mentioned disadvantages of existing virtual portal implementations and, in particular to provide a mechanism to reduce memory consumption and administration requirements in virtual portal environments.